To protect against unauthorized copying and use of software applications, many software vendors utilize some form of product activation procedure. In general, product activation (sometimes referred to as software activation) involves a procedure for verifying the authenticity of a software product, and ensuring that the software product is used within the scope of its end-user license agreement (EULA). In a typical product activation procedure, a software application performs a hash operation to generate a hash of an identifier (ID) specific to a product's license (e.g., a product key) and a hardware serial number, identifying the particular computer or device on which the software application is to be utilized. The resulting hash, which is commonly referred to as an installation ID or a product activation ID, is then sent to a software vendor's license manager to verify the authenticity of the product key, and in some instances, to ensure that the product key is not being used simultaneously for multiple installations on multiple computers or devices. Of course, a variety of alternative product activation procedures exist. As described below, one problem with conventional license managers and product activation procedures is that they are designed to operate only with certain primary software applications, and generally do not support auxiliary software applications or components, such as add-on components or other supporting software applications.
In some instances, one or more software applications may be distributed to end-users in a suite of applications. Some of the applications in the suite may be designated as primary applications or point products, and distributed along with one or more other applications that are designated as auxiliary software applications and/or components. These auxiliary software applications and/or components may be designed to operate with, and generally enhance the functionality of one or more of the primary software applications in the suite of applications. The auxiliary software applications may be stand-alone applications that provide some specialized functionality, or in some cases, the auxiliary software applications may be dependent add-on software components that can only be invoked from another software application. For instance, many software applications are designed with a view to allowing additional functionality to be realized via one or more add-on software components. Web browser applications frequently utilize add-on components to enable the presentation or play back of various audio and video formats. Many video game applications utilize add-on components to provide additional content, such as advanced or customized levels of play, and/or special characters or background scenes. Certain graphics editing programs, such as Adobe Photoshop® from Adobe Systems Incorporated of San Jose, Calif., utilize add-on components to provide support for different graphics file formats, and to provide certain graphic and image processing functions. In any case, whether the auxiliary software components are stand-alone applications, or dependent add-on components, providing each auxiliary component an independent and separate serial number or product key, and requiring that each auxiliary component be subject to the same activation procedure as each primary software product adds to the overall complexity of the licensing and software activation process, thereby adding to the potential cost of delivering the software applications to the end-user.
For example, in FIG. 1, a functional block diagram of the software modules involved in a conventional licensing and product activation scheme, used to enforce the EULA of a primary software application, is shown. In the example presented in FIG. 1, two primary software applications (e.g., Application A and Application B) are installed on the computer system 10. In addition, one auxiliary application (e.g., Application X) and two add-on components (e.g., add-on Y and add-on Z) are shown to be installed on the computer system 10. The applications and add-on components may have been installed together as part of a suite of applications, or independently. In any case, with conventional licensing and software activation mechanisms, only those applications that have been designated as primary software applications are assigned licensing information, such as a serial number or product key, and made subject to an activation process. In this example, a shared license module 12 is shown communicating licensing calls 14 with license information for the primary applications (e.g., Applications A and B) to the license manager module 16 residing and executing on the remote license server 18. Consequently, because auxiliary Application X and add-on components Y and Z are not individually licensed, and therefore not assigned licensing information, such as a serial number or product key, a software vendor or developer has little control over how and when the auxiliary software applications and components are utilized.